VOIDED con las notificaciones habituales y crea un nuevo pedido OPEN con la misma tienda, canal, fulfillment, marca, cliente, productos, modificadores y canjes. Los pagos no se copian.
El vínculo se guarda en metadata.reopen. as_order_id es el reemplazo de este pedido. from_order_id es el pedido que este reemplazó. Pueden estar los dos. Un pedido nuevo se puede colocar y reabrir de nuevo mientras esté CLOSED y se pueda cancelar, sin límite en la cadena. Un reintento sin order_id devuelve el mismo reemplazo.
Un pedido que ya está VOIDED, REVERSED o CANCELLED (legacy) y nunca se cumplió también se puede reabrir, por ejemplo después de una inyección fallida cuyo cobro con tarjeta se reversó en el dispositivo. No se anula ni se cancela nada otra vez y no se envía webhook; solo se crea y vincula el nuevo pedido OPEN. Todos los tenders reales deben haber terminado sin dinero retenido (CANCELLED, FAILED o REFUNDED completo). Mientras una reversa sigue en curso (un tender está PAID) la respuesta es 400 ORDER_PAYMENT_CAPTURED; reintenta cuando llegue el reembolso. Un tender todavía IDLE o PENDING es 422 ORDER_NOT_REOPENABLE. Un pedido REFUNDED o COMPLETED nunca se reabre: un reembolso solo ocurre después de la entrega.
order_id en el cuerpo es opcional. Si lo omites, o no envías cuerpo, el id del pedido nuevo se genera igual que antes (genOrderId(storeId): ord-<tienda>-<12 alfanuméricos en minúscula>). Si envías order_id, ese valor es el id del pedido nuevo. Puede ser cualquier id que arme genId() (isGenId es la misma validación que usa la API). genOrderId es una opción y sigue devolviendo ord-<tienda>-<hash>. genOrderId(storeId, { length, format }) cambia el hash: length es al menos 8 (por defecto 12) y format es alphanumeric (por defecto, 0-9a-z), numeric (0-9) o alphabetic (a-z). Un hash solo es genId().hash(16, "numeric").build(). El separador es opcional, así que un literal puede ir pegado al hash: genId().literal("BB21921").hash(8, "numeric").build() produce un id como BB2192100000001. Un hash de menos de 12 caracteres avisa, y un hash numérico de menos de 16 dígitos avisa; los dos igual devuelven el id. Un hash más corto es más fácil de adivinar y choca más seguido. isGenId acepta [A-Za-z0-9-], máximo 64 caracteres, sin - al inicio, al final o duplicado, y una racha de al menos 8 caracteres [0-9a-z]. Si el formato no coincide, la respuesta es 400 con details.code y code ORDER_ID_INVALID y error order_id does not match the genId format. Si ya existe un pedido vigente con ese id en este comercio y entorno, la respuesta es 409 con details.code y code ORDER_ID_EXISTS y error An order with this id already exists. El mismo 409 se devuelve si el insert pierde una carrera contra orders_id_merchant_env_deleted_unique (Postgres 23505). La unicidad es esa restricción, sobre (id, merchant_id, env, deleted_at). orders.id no tiene una restricción única de una sola columna, y esta API no agrega una.
Requiere un access token de Storefront API de Intercambio de
token.
@fire-spark/storefront, llama order.reopen(). Devuelve el nuevo Order; reemplaza el pedido actual con él. Pasa un id de genId o genOrderId cuando el pedido nuevo debe usar ese código: order.reopen(genOrderId(storeId)). Un id propio es order.reopen(genId().literal("BB21921").hash(8, "numeric").build()). La misma llamada con opciones de genOrderId es order.reopen(genOrderId(storeId, { length: 16, format: "numeric" })). El SDK envía ese valor como order_id. Omite el argumento para conservar el id generado.
Parámetros de ruta
Cuerpo de la solicitud
order_id, envía la misma solicitud sin cuerpo.
Respuesta
Devuelve201 con el nuevo pedido abierto. Reintentar la misma reapertura devuelve 200 con el mismo pedido nuevo.
Las integraciones reciben el mismo webhook
order.voided que en una
cancelación del pedido original.